When it comes to learning, we have all benefited from social learning in the workplace. Social learning is an opportunity for people to learn from one another through programs that help us share knowledge such as peer mentorship, or attending a lunch and learn, where someone shares their expertise with the broader company. Though sometimes unconscious, we are able to learn and observe by example and then apply what we take away to our own work.
Much of social learning is reliant on being in the office. We’re all familiar with someone approaching your desk with a “quick question” that soon turns into a 30-minute over-the-shoulder demo where you are both trying to solve a problem collaboratively. While interactions like these can be disruptive, there is also tremendous value in time spent collaborating with a teammate to explore and find solutions together.
With our team working from home these past months, we’ve had to think more creatively on how we can foster these learning opportunities on our Engineering team. Human connection is vital to how we welcome people onto our team, so we’re hard at work to strengthen it. There’s two moments in time that we wanted to try and simulate: when you first join the company and ongoing day-to-day learning from each other.
Pair Programming in MOLTing
MOLTing is what we call our onboarding period at Cockroach Labs. During this 30-day timeframe, we focus on getting each Roacher up to speed with company knowledge, product knowledge, and role knowledge. For Engineering, we hope by 30 days engineers feel confident submitting PRs and navigating the code base.
The code base for CockroachDB is vast, so we organize at least three pair programming sessions for each new Roacher that joins the team. One is scheduled with their Roachmate, another with a member of their team, and a third with an engineer working on a completely different product area. This way, new Roachers have an opportunity to meet others working on the product that they wouldn’t necessarily interact with during a normal day.
When developing any new program, I recommend always asking yourself: “has anyone done this already?” This way you can learn from peers in your field and evolve programs to work better for your team. A quick search led me to a blog post written by the team at Atlassian on how they’ve made remote pair programming work. It was reassuring to see their confidence in remote pair programming, and their pro-tips on how to best organize these sessions were extremely valuable.
Based on feedback from pilots, we’ve set some guidelines that have been helpful for pair programming with new Roachers:
- The more tenured Roacher should start as the Driver. The pair can feel free to swap roles during the session, but it’s more likely the new Roacher will be asking questions as they are shown the code.
- Determine together what you’ll attempt to accomplish ahead of time. Each new roacher is interested in learning something different. For some, it’s completing a small bug fix on the database code, for others, it’s walking through their product area’s code or getting help completing their starter project. We recommend that people either speak beforehand or open the session with a discussion on what they want to explore.
“Watch Me Work” Office Hours
While the Pair Programming during MOLTing helped ramp engineers up on our code base and product, there was still a gap for those who missed working alongside their peers on complicated problems. This type of learning is organic— in the workplace, you might overhear your colleagues discussing a problem they are trying to solve, leading you to listen, ask questions, and learn something new!
One of engineering managers, Jordan, runs his own Twitch stream where he showcases databases and database programming. Earlier this year, I heard that his team was streaming to each other in a smaller group setting and thought, “how can we encourage this company-wide?” and went about making these sessions more regular. From these streams, you’re able to learn from others how to shape your work, solve problems, investigate, code, test, and build well-structured solutions. We hope it also provides engineers exposure to systems and components outside of the ones they normally work on.
We’ve recruited a couple of our senior engineers to schedule “Watch Me Work” Office Hours on a biweekly basis. Some of them stream their office hours on Twitch, while others use internal Google Meet links. Either way, Roachers are encouraged to drop by, stay as long as they want, and respectfully observe how other engineers write their code. We encourage the hosting engineer to explain their thought processes and share insight into the choices they are making to teach their peers along the way.
We’re grateful for the engineers who’ve set aside time every month to keep the learning accessible and make the sessions feel as “organic” as possible. We’ve even had our CTO, Peter Mattis, use his CTO Office Hours to share his screen and show parts of the code that he’s been working in.
⸺
Each of these programs are learning experiences within themselves. We’re taking in feedback, tweaking the guidelines, and evolving them as we go. One thing we’ve considered as we’ve built programs is how things will scale as we grow our team, and how these programs will apply to whatever our future workplace looks like. Both of these programs, though started as a remote practice, will stay with us in and out of the office.
